わしじゃ〜
2003-10-14 20:08:05 ( ID:7r7iywcwmsa )
[ 削除 / 引用して返信 ]
[バグ内容]
[WAVE ファイル出力] すると Wave File Size が 2Byte 多い。
[再現方法(例)]
1.ソースとして A.m2v と A.wav(fs:48,000Hz) を設定
2.[設定] - [ビデオ詳細タブ] - [ソースの範囲] で、100秒相当の 0-2,996(2,997Frame) で範囲設定
3.[ファイル(F)] - [ファイルに出力(U)] - [WAVE ファイル] で B.wav を出力
[バグと考える理由]
上記の場合100秒の WAVE File(B.wav) が出力されるので、fs 48,000Hz の場合は、
WAVE Header(44Byte) + 48,000 * 100 * 2(16Bit) * 2(L/R) のデータが出力されるので
19,200,044Byte となる筈ですが、19,200,022Byte となります。
出力範囲設定を Frame で行うので若干の誤差が生じるにしても、19,200,022Byte と言う事は、
上記の式から逆算すると 44 + 48,000 * 99 * 2 * 2 + 47,994 * 2 * 2 (+ 2) になっていると考えられます。
すなわち、Wave Header(44Byte) + L(2Byte),R(2Byte),L(2Byte),R(2Byte)...L(2Byte),R(2Byte), L(2Byte) に
なっており、最後に L-Ch が1回余分に出力(2Byte多い)されていると思われます。
※ ソースの範囲を変え20回位試しましたが、全て 2Byte 多くなりました。
ちなみに、この Wave File を Sound Engine Free 2.941 に読込ませて何もせず名前を付けて保存すると、
2Byte 削られて、R-Chで終端する正常な Wave File になります。
※ 現在は、とりあえずこの方法で対応しています。
本来であれば「22Byte短い」と言うべきかも知れませんが、どうやっても「2Byte多く出力」
されるので "2Byte多い" と言う表現にしました。
(22Byte少ないのか、2Byte多いのかの判断は、検証担当さんにお任せします)
以上 "おまけ機能" ではありますが、不具合を発見したので一応報告まで。
Palladion
2003-10-14 22:52:43 ( ID:b13fh8mhibm )
[ 削除 / 引用して返信 ]
出力されたWAVEファイルを見る限り、問題の2バイトは、ヘッダに余分(?)な2バイトが付加されているように見受けられます。
具体的には「dataチャンク」の前の2バイトがそれに当たります。
Sound Engine Free 2.941 に読込ませて何もせず名前を付けて保存した場合は、ヘッダが再生成されてこの2バイトがなくなるのでしょう。
わしじゃ〜
2003-10-15 12:44:50 ( ID:7r7iywcwmsa )
[ 削除 / 引用して返信 ]
Palladion さん検証レス有難うございます。
私もバイナリレベルで確認しました。
下記URLの「wavファイルフォーマット」を見ながら、Sound Engine Free 2.941 で出力し直したファイルと比較した所、
wavヘッダ内の「拡張部分のサイズ」と言われる所に2Byte(0x00,0x00)余分に入っている様です。
下記HPの解説によると、この部分は "リニアPCMならば存在しない" と注記されているので、不要なのではないでしょうか?
※ ちなみに一般的なwavファイルには入っていません。
参考 URL = http://www.kk.iij4u.or.jp/~kondo/wave/
※ 確認した TMPGEnc のバージョンは 2.521.58.169 です。
ちょうき
2003-10-15 23:58:58 ( ID:k7rfhvfrysf )
[ 削除 / 引用して返信 ]
Windowsのサウンドレコーダーとかには付いてますし(w2kです)
実害は特に無いので、恐らくWindowsに合わしたんでは?
昔は結構Windowsと合ってないと駄目だったりするTOOL有ったし
wavだけじゃなくね。
V.K.
2003-10-16 00:20:32 ( ID:varimftn/9f )
[ 削除 / 引用して返信 ]
Microsoft謹製サウンドレコーダでも付加されます。
また、この2バイトは仕様上許されている範囲であり、バグではありません。
RIFFの仕様書をよく見てください。
'fmt 'チャンクサイズが10 00 00 00だとしたら余計なものですが、12 00 00 00(18バイト)だとしたら問題ありません。
以下技術的な話。
プログラム的にいえば、WAVEFORMATEX構造体のcbSize=0かつwFormatTag=WAVE_FORMAT_PCMの時、sizeof(WAVEFORMATEX)-2を'fmt 'チャンクサイズに指定*できる*と考えるべきでしょうね。
通常はsizeof(WAVEFORMATEX)+cbSizeになります。
Win32APIのヘルプを見ていても、WAVE_FORMAT_PCMの場合はcbSizeメンバは無視される、とされています。
'fmt 'チャンクサイズが16バイトだったとしましょう。
WAVEFORMATEX構造体は合計18バイト必要ですが、cbSizeが最後に存在し、そのサイズは2バイト分です。
プログラムはチャンクサイズが16バイトですから、fmtチャンクデータをWAVEFORMAT構造体のエリアへ16バイト分読み込み、APIに渡します。
この状態ではcbSizeは初期化されませんので、値は不定です。
WAVEFORMATEXを要求するAPIはwFormatTagを確認し、WAVE_FORMAT_PCMであるためにcbSizeメンバにアクセスしないため問題が発生しない……ってところでしょうね。
わしじゃ〜
2003-10-16 12:42:49 ( ID:7r7iywcwmsa )
[ 削除 / 引用して返信 ]
ちょうき さん、V.K. さん レスありがとうございます。
> Microsoft謹製サウンドレコーダでも付加されます。
たしかに。Win98版ですが更にfactも追加されてWave Headerが58Byteになっています...
使った事がなかったので、気が付きませんでした。
結論として「現在TMPGEncで出力されるwavは正常の範囲である」言う事、了解しました。
1年位前に簡単なwav分割/結合ソフトを作った時に、先にあげたHPと実際のwavファイル(十数種類)を参考にしたのですが、
その時に検証したwavファイルは全て「Wave Header = 44Byte」だったため "誤った認識" をしてしまった様です。(恥
中々奥が深いですね... 勉強し直します。
本件は、バグレポートとしては取り下げます。お騒がせしました。m(_~_)m
|